A multitude of different types of communication terminals, often referred to simply as “devices”, have been developed for packet-based multimedia communication using IP (Internet Protocol). Multimedia services typically entail transmission of media in different formats and combinations over IP networks. For example, an IP-enabled terminal may exchange media such as visual and/or audio information with another IP-enabled terminal, or may download media from a content server over the Internet.
A network architecture called IMS (IP Multimedia Subsystem) has been developed as a platform for handling and controlling IP-based multimedia services and sessions, commonly referred to as the IMS network or IMS core. Thus, an IMS network can be used to set up and control multimedia sessions for communication terminals connected to various access networks, regardless of the access technology used.
Multimedia sessions are handled by specific session control nodes in the IMS network, e.g. the nodes P-CSCF (Proxy Call Session Control Function), S-CSCF (Serving CSCF), and I-CSCF (Interrogating CSCF). Further, a database node HSS (Home Subscriber Server) in the IMS network stores subscriber and authentication data. The IMS network may further include various application servers and may also be connected to external services providers.
According to the IMS platform, the protocol called “SIP” (Session Initiation Protocol) is generally used to initiate, manage and terminate multimedia sessions. Standard SIP messages can thus be used by IP terminals or devices for establishing sessions, such as the common session initiating message “SIP invite” and the common response message “SIP 200 OK”. The “Session Description Protocol” can also be embedded as a self-contained body within SIP messages, to specify different communication parameters needed for a forthcoming multimedia session. This protocol is generally used to exchange necessary information in session setup procedures, e.g. device capabilities, media properties, currently used IP addresses, etc., as is well-known in the art.
IMS-based services can also be provided for devices in a local or private network such as a residential or office network, sometimes referred to as a LAN (Local Area Network). In this description, the generic term “local network” is used to represent any such networks, and the term “device” is used to represent any terminal capable of IP communication within a local network. In such local networks, a local IP address is allocated to each device for communication within the network, although it cannot be used for routing messages and data in the public domain outside that network.
A local network may include, e.g., fixed and wireless telephones, computers, media players, servers and TV sets. In order to provide IMS services to such devices, a multimedia gateway called “Home IMS Gateway, HIGA” has been defined that can emulate an IMS terminal from the local network towards the IMS network, to access IMS services on behalf of any device in the local network.
UPnP (Universal Plug-and-Play) is an architecture with standardised device protocols for communication within a local network between different devices that may use different access methods, operating systems, programming languages, format standards and communication protocols. Among other things, UPnP supports a process called “discovery” or “pairing”, in which a device can join a local network, obtain a local IP address, announce its name and IP address, and exchange capabilities and services with other devices in the network. In this description, any device capabilities for data transport, communication, encoding, storing and display will be referred to as “capabilities” for short.
UPnP also defines a Remote Access Architecture RAA, enabling remote “UPnP devices” located outside the local network to communicate with devices located within the network. In particular, the RAA specifies how to provision and configure parameters required for enabling remote access connections between entities having a Remote Access Server RAS and a Remote Access Client RAC, respectively. In this field, control points for the RAS and RAC functionality is sometimes generally referred to as the “UPnP RA management console”. However, the UPnP RAA does not provide any solution for making such remote access connections secure, nor how to deliver any credentials or qualifications needed for safe connections. For example, no solution has been presented so far for authenticating or verifying a remote device when accessing the local network from the outside.
In FIG. 1, a local network 100 is shown with different local devices, in this example including a wireless telephone, a fixed telephone, a TV set, a laptop computer, and a media server. The network 100 also includes a conventional gateway 102 referred to as a “residential gateway RGW”, which is connected to an external access network 104 to provide a communication link to other networks and entities. The RGW 102 typically includes a NAT (Network Address Translation) function and a local DHCP (Dynamic Host Configuration Protocol) server, not shown, configured to allocate local IP addresses to the devices, as is well-known in the art.
The local network 100 further includes a HIGA 106 providing a connection to an IMS network 108 in which an HSS 110 is shown. The HIGA 106 has suitable interfaces towards the different devices in network 100 using device-adapted protocols, as indicated by dashed lines. In practice, a HIGA may be integrated in an RGW, but logically it will be considered as an individual functional unit in this description.
The HIGA 106 holds IMS identity information 112 associated with IMS subscriptions and user/service profiles, which can be used for accessing the IMS network 108 where corresponding subscriber information 114 is stored in the HSS node 110. Accordingly, a user can log on to the IMS network from a device in the local network 100 by means of HIGA 106, and the local IP address of the used device can then be associated with a profile of the user. In WO 2006/045706 (Ericsson) it is described how devices in a local network can obtain IMS services by means of a HIGA.
When HIGA 106 receives a request for a multimedia service from a device in network 100 using a device-specific interface/protocol, HIGA 106 translates the service request into a valid IMS request (e.g. SIP invite) on behalf of the device, to set up a session for the device by communicating suitable SIP messages with the IMS network 108. In a similar manner, an IMS session can be set up by HIGA 106 for an incoming request for communication with a device in network 100, by using an IMS identity 112 associated with the device. In either case, any communicated media is routed during the session from or to the device over the RGW 102 and the access network 104, as indicated by two-way arrows.
FIG. 1 further illustrates that a local device 100a in network 100 moves outside to become a remote device 100a′. The remote device 100a′ can then send a SIP invite message to the HIGA 106 over the IMS network 108, to initiate media communication with one of the remaining devices in network 100. The remote device 100a′ must then have a valid IMS identity for accessing the IMS network from outside the network 100.
In order to access a local device in network 100 remotely, the remote device 100a′ must have gained knowledge of the local device somehow in a discovery process. The remote device may have taken part in a regular discovery process recently while being located inside the local network 100, typically involving the exchange of certain discovery messages according to a protocol called SSDP (Simple Session Discovery Protocol). If this is not the case, however, such as when the remote device has in fact never been inside the local network at all, it is necessary to exchange the discovery messages remotely.
FIG. 2 illustrates a possible logic structure in a remote device 200 and a local gateway 202 of a local network, respectively, for enabling remote access to local devices in the network (not shown). The local gateway 202 may be an RGW and/or a HIGA. A Remote Access Client RAC 200a has been configured in the remote device 200 and a corresponding Remote Access Server RAS 202a has been configured in the local gateway 202, which can be done when both are present in the local network since RAC 200a and RAS 202a should be configured with matching profiles.
The RAC 200a comprises a Remote Access Discovery Agent RADA 200b, and the RAS 202a comprises a corresponding Remote Access Discovery Agent RADA 202b, configured to exchange discovery messages between the two entities 200 and 202. The RAC 200a further comprises a Remote Access Transport Agent RATA 200c and the RAS 202a comprises a corresponding Remote Access Transport Agent RATA 202c, configured to establish a transport channel for media between the two entities 200 and 202. Effectively, the RATAs 200c, 202c will act as opposite end points for the remote access.
However, the UPnP RAA dictates that the entities in which a RAC and a RAS are implemented, must be physically present in the same local network in order to execute the necessary discovery or pairing process, which may naturally be a drawback. For example, a UPnP remote access enabled PC device located somewhere on the Internet, cannot get remote access to a device in a local network located somewhere else on the Internet, unless the PC device is first physically brought into the local network to perform the required discovery or pairing process. From a practical and usability viewpoint, this requirement may well be a problem. Moreover, it is also a problem that no trust model can be provided for such remote access, e.g. to verify or validate the remote device towards the local network, or vice versa.